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PROGRESS TOWARD EASIER PROGRAMMING 


Today’s so-called high level programming languages (such as > 
Cosox and pL /1) are really just steps in an evolutionary process of 
making the coding part of programming easier. The terminology 
is unfortunate, because “high level” implies that a language 
plateau has been reached. In order to categorize further devel- 
opments, one is forced to use unsatisfactory terms like “higher 
level” or “very high level.” While the data processing field has 
moved relatively slowly up these steps—from absolute binary to 
symbolic to assembly languages to compiler languages—progress 
is continuing in making the coding function easier. In this report, 
we discuss several such developments (languages that are one or 
more steps above CosBoL, pL/1, etc., as far as ease of use is con- 


cerned) and some user experiences with them. 


L. this report, we will be concerned with some 
developments that are aimed at making the 
programmer/computer interface somewhat less 
demanding for the programmer. We are using the 


term “programmer’’ in its broadest sense, to ap-. 


ply to anyone who creates new procedures for the 
computer to follow. Not only is the interface 
being made easier for professional programmers, 
but it is also being improved so that non- 
programmers can create procedures for 
computers. 

In a business-type organization, there is a spec- 
trum of people who might create procedures for 
the computer. Listed in the order of decreasing 
amount of programming training required, they 
are: 


System software programmers 

Application programmers 

Analyst/ programmers 

Professionals using computers in their work 
Business system analysts 

User department personnel 

User department managers 

Executives 


The goal of the developments we will be dis- 
cussing is to make it easier for all of these types to 
use the computer. This does not imply that all will 
be dealing with the same complexity of proce- 
dures; rather, each will deal with procedures that 
are appropriate to his or her job. 

The approach taken with most of these devel- 
opments has been that of higher level languages. 
As Leavenworth and Sammet (Reference 1) say, 
the term “high level” is relative. They trace the 
evolution of languages away from the need to 
specify how something is done and toward the 
specifying of what should be done. But the state- 
of-the-art is not at the point yet where just the 
what need be specified. 

What are the characteristics of today’s higher 
level languages, as compared with the norm such 
as CoBoL and pL/1? Here is how we see it. 


CHARACTERISTICS OF HLL 


As compared with COBOL or PL/1, a HLL: 
1. Has more powerful commands that do more than typical 
conventional commands. 
2. Is not necessarily as rich nor as flexible a language, but is 
still a “complete” language that can be used for pro- 
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gramming a complete application system. 

3. Can be learned more quickly and easily; as a byproduct 
of this characteristic, finding good programmers in the 
language should not be as difficult as finding good CoBoL 
or PL/] programmers. 

4. Helps to structure the program design, by assisting in 
handling complexity. 

5. Has default options for housekeeping functions, such as 
open and close files, relieving the programmer of these 
routine duties. 

6. Eventually will be largely nonprocedural, wherein the 
user specifies what is to be accomplished rather than 
how it will be done. 


There are several types of computer languages 
that we are not including within our discussion in 
this report. These are: 

¢ Shorthand processors for conventional 

languages 

¢ Data definition and data manipulation 

languages 

¢ Job control languages 

¢ Small system languages, such as rpc and 

RPG II 

¢ Query languages 

The criterion we used in selection was: can the 
language largely or completely replace CoBoL 
or PL/1 in a medium to large size installation? 
Some come close; RPG IIT has supplanted CoBot in 
small to medium size installations, and query lan- 
guages have almost completely replaced CoBoL 
for creating ad hoc reports at many places. But 
we chose to draw the line according to the crite- 
rion just given. 

Want to change languages? 


If a user organization is considering changing 
its “standard” programming language, in order to 
make programming easier, several options are 
available. For this discussion, we will assume that 
the organization is currrently using ANS COBOL. 
Here are the major options, as we see them: 


CURRENT OPTIONS IN HLL 

1. Change to a Cosot-based HLL; preprocessor used to 
convert the language statements to ANs CoBOL. 

2. Change to a structured generator language that is di- 
rectly compiled into object code, without going through 
Coso .. 

3. Supplement Cosox with one or more specialized lan- 
guages that are appropriate for particular applications. 


We have not included among the options the 
choice of converting from Cosox to, say, pL/1. As 
far as we are concerned, PL/1 is essentially at the 
same programming level as Cosot (without get- 
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ting into a discussion of the merits of each lan- 
guage). It is for this same reason that we did not 
include shorthand processors for today’s conven- 
tional languages; the level remains the same but 
the verbiage is reduced. (For readers who are in- 
terested in this type of change, Reference 2 has a 
discussion of the problems involved; for instance, 
Harold discusses the Cosot to pL/1 change, but 
the remarks could apply to any change of pro- 
gramming languages.) 

A main factor in the choice among the various 
options, of course, is the type of user who will use 
the language. For the purposes of this report, we 
will concentrate on languages designed for appli- 
cation programmers, analyst/programmers, busi- 
ness system analysts, and end users. 

Here, then, are user experiences with several 


higher level languages. 


COBOL-based higher level languages 


As mentioned above, CoBpou-based HLLS are 
translated (by a preprocessor) into ANs CoBoL 
source code. The Coxso. code must then be com- 
piled into object code in a conventional manner. 
The “higher” level of the language is achieved by 
either the use of CoBoL macro-instructions or by 
the use of a very different language that is trans- 
lated into COBOL. 

Included in this category are both program and 
application system generators. With generators, 
the user provides values of parameters; the gener- 
ators then generate the CoBot source code (in this 
category, at least). 

We will discuss user experiences with four sys- 
tems in this category: MetacoBoL, Work TEN, 
CL*tv, and GENASYS. 


MetaCOBOL 


Metropolitan Life Insurance Company, with 
headquarters in New York City, has assets of al- 
most $33 billion and employs over 45,000 people. 
The company has four data processing centers in 
the U. S., in New York City; Scranton, Pennsylva- 
nia; Wichita, Kansas; and Greenville, South Caro- 
lina. Metropolitan Life uses multiple vendors, 
having both IBM 370 and Honeywell equipment 
installed and an H-66/20 on order. 

Essentially all applications programming on 
the IBM equipment is done in CosoL, and the 
plan for the future is to become an all-CosBoL 
shop. In order to provide a better degree of pro- 


gram transferability between its computer sys- 
tems, the company has developed its own 
standard subset of CoBoL. 

In 1972, Metropolitan Life acquired Meta- 
COBOL. One reason for choosing MetacoBoL was 
to provide efficient Copot macro-instructions for 
frequently occurring functions. Another reason 
was to use the MetacoBOL preprocessor as a 
Coso.u standards enforcement tool. 

The CosoL macros are developed by the com- 
pany’s system programmers, who are quite care- 
ful about this implementation. They want to 
avoid conflicts between different macros, and 
they want to achieve as high a degree of effi- 
ciency as they can in the macros. One group in 
systems programming is responsible for the coor- 
dination of the development and maintenance of 
macros to avoid or eliminate conflicts. 

Once macros have been developed, they are 
entered into a coordinated macro library for use 
by programmers. Some macros are called out by 
application programmers in the programs they 
write. Other macros analyze the application pro- 
grams during the MetacogBoL preprocessing step 
for compliance with programming standards. 
Still others have been used for converting existing 
programs from, say, GE Cospo. to IBM Coso.. 

Currently, Metropolitan has been using using 
MetacoBoL to convert its GE435 CosBoL pro- 
grams to IBM Cosou as well as to develop an 
automatic test data generator. When completed, 
the Toe will require little if any input from a pro- 
grammer, but, rather, will analyze a program to 
locate and examine all conditional instructions 
and then automatically create test cases for test- 
ing all paths. Metropolitan Life already has plans 
to use the facilities of Metacogpo. for other pur- 
poses in its computing environment. 

MetacosBo. is a generalized macro pre- 
processor operating under Dos or os on IBM 360 
and 370 systems. Applied Data Research, Inc., de- 
velopers of Metacopo., has continued to an- 
nounce improvements and enhancements to it. 


There are a number of elements of the Meta- 
COBOL system. The MetacosBou translator in- 
cludes the macro translator and library facilities 
for a shorthand, a standards enforcer, a COBOL 
source program optimizer, and a major logic gen- 
erator. The major logic generator generates 
Cosou source code for file matching, input edit- 
ing, and report writing. It also includes con- 
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version facilities for converting from the earlier 
IBM 360, Honeywell D and H, and RCA Spectra 
Cosou source code. A test data generator creates 
test data for debugging programs. The run-time 
debugging aid reports the location and cause of 
one or more clerical errors and the contents of in- 
put, output and intermediate fields during pro- 
gram testing. And a Cosou Performance Monitor 
analyzes and reports on program activity by para- 
graph—isolating critical processing and input/ 
output activity and counting paragraph entries. | 

The Metacoso x translator makes use of a pro- 
gram development macro library. Users can de- 
fine higher level verbs for frequently used 
functions, and express those verbs in CoBoL 
source code. When the translator encounters such 
a verb, it replaces it with the appropriate CoBoL 
source code. MetacoBot can also be used to inter- 
face COBOL programs to data management sys- 
tems such as IMs or TOTAL or to monitor programs 
such as CICS. 

ADR has also developed structured program- 
ming facilities for the Copor language. This facil- 
ity includes a modular discipline, under which 
each module of a program has a standard format. 
This format includes an identification section, a 
data section (for locally defined data), and a 
procedure section. 

Several language changes have been made for 
supporting structured programming. The coro 
verb has been eliminated. The 1F statement has 
been changed. A Cosou IF statement requires a 
period to terminate it—but a period terminates all 
outstanding iF statements. With Coso_, it is hard 
to nest a hierarchy of 1F statements without using 
GoTo. So MetacosBou has added ENp1F to the IF 
statement (IF ... ELSE ... ENDIF) which termi- 
nates only the most recent IF. 

Dow3uiL_ is one of the basic structured pro- 
gramming control structures. The procedure is 
performed if the test is true, and is exited if the 
test is false. 

MetacoBo_ has been in use since 1970, There 
are now some 275 organizations worldwide using 
it. 

For more information on MetacoBo., see Ref- 
ererices 3 and 6. 


WORK TEN 


National Steel and Shipbuilding Company 
(Nassco), with headquarters in San Diego, Cali- 


fornia, constructs and repairs ocean-going ships. 
Annual sales are in the order of $200 million and 
the company employs some 5,000 people. Their 
data processing is performed on an IBM 370/145 
with a 384K memory, operating under Dos/vs. 
They have eight programmers, two analysts, and 
two system programmers. Languages used are 
CosBo.L, ALC, DyL 260, and Work TEN. 

In 1971, Nassco learned that other companies 
around the country were successfully using 
Work TEN. Nassco was not too happy with the 
verbosity of CoBox and began looking into avail- 
able packages. They selected Work TEN and 
have used it for essentially all batch programs 
since that time. They had not been using it for ap- 
plication programs operating in a teleprocessing 
mode; those programs were written in CoBoL. 
One-time jobs, such as ad hoc reports, have been 
written in Dy 260. 

Work TEN is a COBOL source program gener- 
ator. Coding is done via a set of structured forms. 
The Work TEN preprocessor generates Ans Co- 
BOL source coding, using symbolic data names. 
The Cogo. source code is then compiled to give 
the object code. 

Nassco has found that, on the average, WorK 
TEN requires about 60-65% of the time required 
to develop and debug the same program in 
Coso.. A programmer who knows CosBo can use 
Work TEN better than one who does not. The 
quality of the object code—in terms of amount of 
memory used and execution time—is probably 
competitive with CosoL, everything considered, 
in their opinion. It might be possible to make 
more efficient use of resources using CoBOL, but it 
would require more skilled programmers, they 
believe. Work TEN tends to enforce discipline; 
for instance, it is easier for the programmer to use 
the file library than it is to bypass it—so the result 
is more consistent data definitions. Work TEN is 
very reliable and relatively easy to learn; expe- 
rienced CosoL programmers are in productive 
use of it after two weeks of training and beginning 
use. 
One typical job involved the batch updating of 
an inventory file. The program made use of two 
input and two output files, all of which had been 
previously defined in the file library. It required 
only four man-days to code and test the program 
according to specifications. The object program 
used about 45K bytes of memory. 
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Nassco recently reassessed their use of Work 
Ten. They wondered if they should move to an- 
other language, which they could use for both 
batch and on-line application systems. They de- 
cided that they very much liked what Work TEN 
was doing for them and that they would consider 
using it for the on-line programs. 

Work TEN is marketed and supported by Na- 
tional Computing Industries of Atlanta, Georgia. 
As indicated above, it is a CoBoL generative file 
management system. As NCI says, “Work TEN 
automatically generates the necessary logic to 
perform the mechanical, repetitive tasks of pro- 
gramming. These tasks include opening and 
closing files, reading transactions, reading master 
records, matching transactions to master records, 
rolling and clearing control break accumulators, 
writing master records, printer control, etc. It 
runs on an IBM 360/370 with a minimum of 65K 
characters of memory. 

Four structured forms are used in programm- 
ing via Work TEN. The work sheet is used to 
record the analyst’s narrative description of the 
program. The field/record sheet is used to specify 
the Cosou identification and environment divi- 
sion entries, plus file and record definitions, but in 
a much more concise form than Coot. The stor- 
age form corresponds to the CosBot working stor- 
age definition, but again is expressed in more 
concise form. Finally, the procedure form corre- 
sponds to the Cosox Procedure Division. A spe- 
cial set of verbs, similar to COBOL verbs, are used 
for specifying the procedures. 

NCI claims Worx TEN to be an easy discipline 
for implementing structured programming. They 
call their approach aspr (Automatic Structured 
Programming Technique). Aspr actually, pro- 
duces a top down design automatically, without 
the use of special verbs or rules to follow. Using 
aspt, the programmer performs the coding of 
program modules or stubs. The modules have one 
entry point and one exit point. The use of Go To is 
restricted to referencing another line of code 
within the same module or referencing the exit 
point of the module. The programmer is pre- 
vented from invoking any coding at the current or 
higher level by aspt. The main line control logic, 
plus the logic to perform the mechanical tasks de- 
scribed above, are automatically generated by 
Work TEN in a hierarchical manner. 

For more information on Work TEN, see Ref- 


erences 3 and 7, at the end of this report. 


CL*IV 

The Arizona Bank, with headquarters in Phoe- 
nix, has assets of over $900 million and 70 
branches in Arizona. For their data processing, 
they use an IBM 370/158 with 1M bytes of mem- 
ory. They are in the process of converting from 
pos to vsl. They employ about 25 programmers, 
and the languages used include CoBot, BAL, CUL- 
PRIT (for ad hoc reports) and CL * trv. 

The management policy at Arizona Bank is to 
purchase as much of their application software as 
possible, rather than develop it in-house. If a soft- 
ware package does not quite meet their needs, 
however, and if they cannot arrange for the ven- 
dor to make the needed changes, they will make 
the changes in house. Most of the work of their 
programmers is in maintaining and extending the 
application systems that have been purchased. 

In 1971, Arizona Bank entered into a contract 
with GSI, Inc., a Phoenix-based software com- 
pany, to develop a portion of a time deposit ac- 
counting system. GSI had some ideas for a new 
language, CL* rv, and they felt they could develop 
it as a part of the contract. Some of the principals 
of GSI had previously developed a similar lan- 
guage and so had experience with this type of 
software. GSI suggested that they develop the 
new language and write the application system in 
it, and the Bank would have a permanent license 
to use the language and preprocessor. After going 
over the plans for the language and preprocessor, 
the Bank agreed to the proposal. 

Previous to 1971, the Bank had obtained an ap- 
plication system that was written in one of the 
commercial higher level languages that produced 
CoBo. source programs. In that case, the Bank 
did not obtain the preprocessor or the HLL pro- 
grams; instead, it received just the CoBoL source 
code that had been generated by the pre- 
processor. The Bank found this code hard to 
maintain, due to the way the data names had been 
assigned by the HLL and due to the difficulty of 
changing the file matching code generated by the 
HLL. If they had received the programs in HLL 
form, along with the preprocessor, this mainte- 
nance would have been no problem. But with 
only the CosBoL source code, maintenance was 
difficult. So, with Cu *t1v, they insisted on getting 
the preprocessor and the programs in HLL form. 
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(In November 1972, GSI sold all rights in CL*1Vv 
to Informatics Mark tv Systems Co., which mar- 
kets the well-known Mark Iv file management 
system.) 

Two of the five sub-systems of the time deposit 
accounting system were written in CL*1v under 
the contract. The two sub-systems went into op- 
eration in 1973, and the Bank has been maintain- 
ing them since that time. They have found CL*iv 
easy to use. CL“1v generates ANS CosBoL, which is 
then compiled to produce the object code. While 
the Bank could maintain the programs from the 
Coso_ source code, they prefer to maintain it via 
Ci*iv. The data names that are generated are 
very understandable. All programs are structured 
the same way, so the programmers know just 
where to look for the code that is to be changed. 
Essentially all debugging is done at the CL*1v 
source level; seldom do the programmers look at 
the CoBoL source. 

When the Bank started to convert from pos to 
vsl, they selected the CL*1v programs for the first 
conversion. As far as the application programs 
were concerned, all the Bank had to do was 
change one card in each CL*1v source deck and 
then rerun that deck through the preprocessor. It 
required only three man-months to convert 51 
programs, including creating the jcx, testing, and 
documentation. 

CxL*1v is marketed and supported by Infor- 
matics Mark Iv Systems Co., of Canoga Park, 
California, and 14 other locations in the U. S., 
Canada, Europe, and Japan. CL" Iv is an enhance- 
ment to ANs CoBoL. It operates on the IBM 360/ 
370 under pos, pos/vs, os, vsl, and vs2. 

When using CL*Iv, the application logic is 
written in ANs CoBOL. A simple syntax is used for 
the identification, environment, and data division 
entries. COBOL source code is generated for rou- 
tine procedural functions, from parameters sup- 
plied by the programmer. These include: the 
main line control structure; file management 
functions such as opening and closing files, read- 
ing and writing records, record matching, detect- 
ing end-of-file, etc.; setting up print lines; 
accumulator management; and control break 


logic. 


Cx*1v adds two powerful verbs as an enhance- 
ment to the CosBot verbs. One is the PRINT verb. 
It eliminates having to write a lot of MovE oper- 
ations and having to set up lines of print. When- 


ever the PRINT verb is compiled, it creates a 
sample report format so that the programmer can 
check what the report will look like. The other is 
the INITIALIZE verb. It creates new occurrences of 
records and sets each field in the record to spaces 
or zeros, depending on the elementary picture. 
The INITIALIZE verb is also used for clearing any 
group or elementary item, such as tables, hold 
areas, etc., defined in the program. 

In addition, users can pre-define data defini- 
tions or paragraphs and sections of procedural 
code and store these in the source library. These 
areas of code can be inserted in CL*1v programs 
by means of a copyH command. 

CL*tv imposes no artificial restrictions on ANs 
Coso . All access methods and storage devices al- 
lowed by Ans Cosot are supported by CL*1v. 

For more information on CL*tv, see Reference 


8. 
GENASYS 


The University of California’s Information Sys- 
tems Division, which is part of the Office of the 
President, is located in Berkeley, Calif. ISD han- 
dles the development of computer-based systems 
for administrative functions of the university. For 
the data processing in Berkeley, they have an 
IBM 360/65 and a 360/30. 

In 1972, one of the University Extension pro- 
grams wanted ISD to develop an application sys- 
tem on an urgent basis. ISD just did not have the 
resources to meet the tight time schedule and sug- 
gested that the system might be developed by an 
outside contractor. A contract was awarded to 
study the requirements and develop the specifica- 
tions for the new system. The programming of 
the system was to be done under another 
contract, where the bids were based on the system 
specifications. 

It was at this bidding stage for the program- 
ming that things got interesting, we were told. 
Bids were requested from about a dozen con- 
tractors and three bids were received. Of these, 
the lowest was from International Computer 
Trading Corporation, in San Francisco. It was 
about one-half the price of the next lowest bid, 
and furthermore, it was a fixed price bid. It was 
based on ICT’s use of their GENAsys service. 
ICT was given the contract, and delivered on 
schedule. 

Genasys is a set of generators for generating 
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application system programs, in source code 
form. The source code may be Ans Cosou or 
pL/1. In the University’s case, they are a PL/1 
shop and so they requested that the programs be 
deliverd in pi/1 code. 

Based on this successful use of GENAsys, the In- 
formation Systems Division made sure it was con- 
sidered in two other cases. One of these—a 
treasurer's information system—had the system 
specifications developed by an outside contractor 
before bids for the programming were requested. 
In this instance, only two bids were received—and 
again, ICT was the low bidder with a bid price al- 
most one-half of the other. In the other case, the 
ISD people developed the system specifications 
in-house and put them out to bid—and ICT was 
the only bidder. In both of these latter instances, 
the bids from ICT were fixed price. But the treas- 
urer's information system contract had to be re- 
negotiated because the specifications that had 
been developed by another outside contractor 
proved to be incomplete. So additional time and 
cost were needed for completing the specifica- 
tions. Except for this delay, the programs were 
delivered about on schedule. 

What about the maintenace of the programs 
generated by GEenasys, we asked. First of all, we 
were told, if any bugs are uncovered that were 
caused by Genasys, ICT corrects these. But for 
modifications and enhancements, the programs 
have proved to be quite maintainable. The pro- 
grams have a common structure, so the program- 
mer knows where to look for the code to be 
changed. And the naming standards become clear 
upon study. Genasys does make a different use of 
resources than their own programmers might, we 
were told, and additional time was required dur- 
ing final debugging stages than might be needed if 
the work was being done in-house. But GENAsys 
did get the jobs done for the University. 

Genasys is based on the concept of standard 
system architectures, expressed in terms of system 
generator software. ICT people believe, based on 
their experiences to date, that these standard sys- 
tem architectures can meet from 80% to 90% of 
the needs of any given business application sys- 
tem. The other 10% to 20% of the needs must be 
met by custom programming. ICT has developed 
four standard system designs. The ICT analyst se- 
lects the design that best meets the need of the ap- 
plication system, in any given case. 


Input for Genasys is developed by means of a 
specification workbook, with questionnaire-like 
forms, plus copies of all input forms and reports. 
Master files are defined and requirements for 
tailor-made procedures and/or reports are identi- 
fied. At this point, the ICT production unit takes 
over. Using the collected material, plus Genasys 
(in the design mode), the production unit pro- 
duces the first version of a design manual. This 
manual contains extensive documentation about 
the system. 

At this point, the ICT analyst on the job sits 
down with the customer’s representative, to see if 
the design is on the right track. ICT finds that an 
average of about two weeks have elapsed to this 
point, since the time that the contract was signed. 
Any changes are noted in the design manual, 
which is then returned to the ICT production 
unit. Using the change data, the next version of 
the design manual is created. This version is more 
detailed than the first, and default options are 


spelled out. The design is reviewed with the ICT 


analyst on the job, and any necessary corrections 
are made. 

Then, using Genasys in the generate mode, 
source programs are created in either ANs CoBoL 
or PL/1. The programs are compiled and any syn- 
tactical errors are corrected. Then they recom- 
pile the programs, produce the necessary JcL 
code, and produce the revised documentation 
manual. 

During this same period, the analyst on the job 
has been working with the customer to develop 
acceptance data. ICT finds they need this test 
data typically by the third week of the project. 
Two options are provided for testing: the testing 
may be done either at ICT or on the customer’s 
machine. ICT prefers the former case. Out of this 
testing comes the need for more changes. The 
ICT production unit makes the changes and re- 
generates the source code. The source programs 
are then generally ready to turn over to the cus- 
tomer. Average total elapsed time—30 to 35 
working days. 

In addition, ICT conducts a training class to ac- 
quaint the customer with the application sys- 
tem—naming conventions, logic of all programs, 
etc. The customer must be in a position to main- 
tain the system (which is in ANs Cosou or PL/1) 
from that time onward. 

To date, ICT has concentrated on selling the 
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GENASYS service, as discussed. However, arrange- 
ments can be made for leasing the GENasys pack- 
age, for those organizations that would want to 
make extensive use of it. 

For more information on GeEnasys, see Refer- 
ence 9. 


Structured generator languages 


This category of HLL probably should be sub- 
titled: “Ones that make a complete break with 
Cosou.” It is possible to have structured gener- 
ator languages that produce Ans CoBoL; we dis- 
cussed two such (Work TEN and GEnasys) above. 
But it is also possible for them to produce object 
code directly. This is the type of structured gener- 
ator language we will be discussing in this section. 

Structured generator languages have been 
called by various names in years past. “File man- 
agement systems, “file maintenance generators, 
and “report program generators’ are terms that 
have been applied to this type of language. Typi- 
cally, these languages have used structured forms 
that can be filled in with a fraction of the writing 
effort of, say, a CoBoL program. For the file defi- 
nitions, for instance, the form might ask: Standard 
labels? Non-standard labels? No labels? If the pro- 
grammer checks that standard labels are to be 
used, pre-defined routines for creating and han- 
dling the standard labels will automatically be 
embedded in the program. Also, for queries and 
conditional expressions, a standard format is laid 
out on the form: Field No. 1, Relational Operator 
(Equals, Not Equals, Less Than, etc.), Field No. 2 
(or literal expression), and action to take. Com- 
plex conditions, where a series of relations are 
joined by Ands and Ors, are simply expressed on a 
series of lines on the form. 

Included in this category are the Mark Iv and 
Asi-sT file management systems. We have dis- 
cussed both of these systems in previous issues, 
particularly the April 1970 report, and will not 
repeat the discussion here. Both are very popular. 
MakRK Iv is used at some 800 installations, and 
Asi-sT is used at over 100 installations. 

Another popular structured generator system is 
the Adpac system, which is in use at over 150 in- 
stallations. We have not previously discussed 
Adpac, and so will include it in this report. 

Also, an interesting enhancement has been 
made to AsiI-sT, to promote its use by the end user 
market. This is an on-line version, called Conver- 


sational Asi1-sT. We will discuss it, too. 

It should be mentioned that some users of this 
type of language have reported to us that their 
programmers resist using the language. Perhaps 
the ease of filling in the forms implies a down- 
grading of their programming talents, in their 
minds. But where data processing managements 
have seen the value of such languages and have 
firmly supported their use, the benefits have been 
impressive. 


Adpac 


Matson Navigation Company, with headquar- 
ters in San Francisco, California, is a pioneer and 
leader in the transportation of containerized 
ocean freight. The company operates 14 vessels 
between the United States Pacific Coast, Hawaii, 
and Guam. The company has almost 2,000 em- 
ployees. For their data processing, they use an 
IBM 370/135 with 192K bytes of memory, oper- 
ating under pos/vs. The installation not only 
processes local batch work but also on-line serv- 
ices for terminals located in several facilities 
along the West Coast of the U.S. and Canada. 
They have nine programmers and three system 
analysts. About 85% of their 2,000 active pro- 
grams have been written in Adpac, about 10% in 
assembly language, and the remainder in CoBou. 
Cosot is being phased out. 

Matson purchased Adpac in 1965 to help lessen 
a potential major conversion effort from IBM 
1400-series equipment to the then new 360/30s. 
Since Adpac programs are machine independent, 
code written for the 1400 computer was directly 
usable by the 360 version with only trivial code 
changes. Thus, with the conversion in the offing, 
Matson experimented with new programs in 
Adpac so that the conversion could be eased. 
They continued to use Adpac as one of their pro- 
gramming tools until 1969, although most of the 
programming was done in Coot and Assembler 
Language after the 360/30 and the 360/40 were 
installed. 

In 1969, Matson was faced with the need to 
program a complicated freight documentation, 
operations and statistics system. They estimated 
the programming job at well over 50 man-years. 
With their project team of ten programmers and 
two systems analysts, this just looked like too big 
an effort to implement in Cosor with the target 
completion date. Since they had used Adpac and 
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were quite impressed with it, they considered it. 
It looked like the whole job might be done in 
about 32 man-years—still a big effort, but substan- 
tially below that of their estimated Cosot time. 

By 1971, the programming on the freight sys- 
tem was going so well that Matson decided to 
standardize on Adpac. Since that time, essentially 
all new batch programs have been written in 
Adpac. Cosot has been used only for maintaining 
the old programs, and these have been almost 
completely phased out. 

Adpac uses structured forms, of the type de- 
scribed earlier. A one-pass compiler generates re- 
locatable object code for the IBM 360/370. 
Compiling time is about at card read speed; a 500 
card program can be compiled in less than one 
minute. 

Adpac generates either user defined or stand- 
ard structures for its programs, and Matson finds 
that this makes program maintenance much eas- 
ier than it is with free-form programs in other lan- 
guages. The programmers know just where to 
look in the program structure for the code that is 
going to be changed. In fact, most of Matson’s 
program maintenance time (for “fire-fighting” is 
now going into the 100 or so CoBoL programs 
that are still active. 

Compared with Cosot, Matson says that many 
fewer input cards are required in order to create 
the same program, by a factor of 2 or 3 to 1. While 
they have not tried to parallel program a total sys- 
tem concurrently with both Adpac and Cosot, 
based upon recoding many programs in Adpac, 
they have found that Adpac is saving significant 
programmer time (for design, code, test, and 
documentation) in the same proportion as the re- 


- duction in input cards. The code generated by 


Adpac is at least as good as Cosot in efficiency— 
that is, in memory usage and in execution time. 
As an example of use, Matson quoted the time 
required to create a simple program for calcu- 
lating and printing some shipping tariff rates. All 
input files were already in existence. It took 35 
minutes to write the Adpac program, which re- 
sulted in 205 cards. Compile time was a total of 
one minute and seven seconds—of which about 25 
seconds was the compile time and the rest was 
link edit time. Two test shots were required, and 
then the program was ready to go. The com- 
plexity of problems programmed have ranged 
from simple to complex, where the latter might 


have over 2,000 coded cards, with from one to six 
instructions per card. 

Matson feels that any user who is considering 
this type of system should give it a fair test, for at 
least two to three months. It takes this long to 
learn to “think” in Adpac and get the most out of 
it. Experienced assembly language programmers 
can learn it in less time. 

Adpac is a structured language, with defined 
logic for the routine portions of a program. These 
portions include file open and close, read and 
write records, record matching, and so on. A CALL 
facility is available for using object modules in the 
program library, and a copy facility can be used 
for copying data descriptions, procedures, and 
even whole programs from the source library. Re- 
cent changes improve Adpac’s performance in a 
virtual storage environment. 

Each Adpac program has the same structure, 
with four divisions in the coding forms. These 
four divisions are: input-output, data, process 
control, and instructions. The process control di- 
vision defines the flow of control in the program. 
Each division has a specific coding form, with (in 
general) a fixed format. The exception is that, for 
algebraic equations, Adpac uses Forrran-like 
free-form coding. 

There are five major components of Adpac II 
software. The program generator-compiler is a 
one-pass processor that translates the Adpac in- 
put into object code. For the routine processes 
just mentioned, it generates the code from rela- 
tively few parameters from the input forms. 
Adpac also includes a text editor, a source library 
management system, an Adpac-to-COBOL trans- 
lator, and a program specifications writer. 

In Adpac, each program is stand-alone. All data 
names are unique to that program. When data 
definitions are copied from the library, they are 
redefined for the new program. Within a pro- 
gram, the file names are one character in length, 
and data names and sub-routine names are three 
characters in length. (Matson told us that these re- 
strictions imposed no particular problems on 
them.) 

For more information about Adpac, see Refer- 
ences 3 and 10. 


Conversational ASI-ST 


Combustion Engineering, Inc., with headquar- 
ters in Stamford, Connecticut, is a major manu- 
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tacturer of steam generating and other indus- 
trial equipment. Its sales in 1974 were in excess of 
$1.4 billion, and the company has over 40,000 
employees. 

For its main data processing, Combusion Engi- 
neering uses an IBM 370/158 and a 370/168 lo- 
cated at Windsor, Connecticut, near Hartford. 
The main programming languages used are 
CoBoL, PL/1, FoRTRAN, and Asi-sT. There are 
about 200 employees with job titles of program- 
mer, an almost equal number of system analysts, 
and a large number of end users who desire to in- 
teract directly with the computer. We discussed 
Combustion Engineering’s use of Asi-st, TOTAL, 
Tso, and INTERCOMM in our June 1973 report. 

The company has been using AsiI-sT since 1969. 
They have used it not only for one-time jobs (such 
as ad hoc reports) but also for programming com- 
plete application systems where appropriate. 
AsI-sT is a preprogrammed data management sys- 
tem that uses basic structures for input validation, 
update and file maintenance, reporting, and such. 
In the regular use of Ast-sT, the users fill out struc- 
tured forms, from which key punching is done, or 
they enter the data on cassettes via Datapoint ter- 
minals. And when Combustion Engineering used 
AsI-sT with Tso, as we discussed in our earlier re- 
port, the user essentially filled out the Asi-st 
forms and used the terminal much as a keypunch, 
entering characters representing desired options 
in specific character positions on a line. 

But this interface—regular Asi-st under Tso— 
was not a convenient one for end users to use. 
They had to fill out the structured forms and simu- 
late keypunching at the terminal. And there was 
some resistance from programmers to filling 
out such forms, perhaps on the basis that such 
activity did not use their programming talents 
sufficiently. 

Applications Software Inc., developers and 
marketers of Asi-st, introduced Conversational 
Asi-sT in 1973. It is a front-end package for Asr- 
st. Combusion Engineering installed Conversa- 
tional Asi-st in 1974, still operating under Tso. It 
is a high level language for use at a terminal. It 
provides a free form (unstructured) language ca- 
pability and can prompt the user for the needed 
parameter values. The front-end makes diagnos- 
tic checks, indicates errors to the user, and passes 
correct statements on to Asi-sT. The language 
translator can also be used in the batch made for 


those who want to use the free form language. 

Combustion Engineering uses Asi-st for essen- 
tially all ad hoc reports. But training in the use of 
Conversational Ast1-sT is in the build-up phase, so 
that only a fraction of the ad hoc reports as yet are 
requested through it. There is some evidence that 
system analysts and programmers are more will- 
ing to use the free form language of Conversa- 
tional Asi-st than they were to filling out regular 
Asi-st coding forms. An ad hoc report request 
generally takes less than one hour, from the time 
the request is written until the report is returned 
to the user. 

Further, the people at Combustion Engineer- 
ing find that it is possible to program a fairly ex- 
tensive application with Asi-st or Conversational 
Ast-sT in a fraction of the time it would take to do 
the same job with a conventional programming 
language. Man-months of effort can be shortened 
to man-weeks, in such cases. 

While it is hard to compare the coding efforts 
required with different languages, Combustion 
Engineering estimates a 10 to 1, or better, reduc- 
tion in the number of lines of code needed with 
Asi-st or Conversational Asi-st, as compared 
wtih CoBo.. 

As mentioned, Conversational Asi-stT was de- 
veloped and is marketed and supported by Appli- 
cations Software Inc. of Torrance, California. It is 
an enhancement to AsI-sT; a user would need 
AsI-sT, to which the conversational package can 
be added. We discussed Asi-st in the April 1970 
report. 

Conversational Asi-stT is designed to run on the 
IBM 360/370 under Tso, IMs DC, and cics. It con- 
sists of five main elements: AsiI-sT, the Conversa- 
tional Asi-st Language, a preprocessor, an 
extended interactive facility, and a macro lan- 
guage option. Using a terminal, the user enters a 
statement in a free but somewhat coded form. 
The preprocessor scans the statement, checks for 
syntax errors, and notifies the user of errors. After 
corrections have been made, the preprocessor 
translates the statement into a fixed-field Asi-st 
statement. When the complete request, or a set of 
requests, has been entered, they are transmitted 
to batch Asi-st for execution. 

The extended interactive facility extends the 
system to a communications environment. The 
command language uses simple words (change, 
delete, find, etc.), an on-line text editor, and a li- 
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brary management facility. With the latter, users 
may save files from session to session; the facility 
also provides accounting control information and 
the monitoring of file passwords. 

With the macro language option, programmers 
may produce their own commands and sub- 
commands. Also, they can write interactive appli- 
cation programs that can communicate with 
users, using terms that are familiar to those users. 
Moreover, it can be used to develop terminal ori- 
ented dialog which prompts users for data that is 
required by any program, regardless of whether 
Asi-stT is involved in the process. The option in- 
cludes the macro language and a macro language 
processor. 

ASI has recently announced Asi/INQUIRY, an 
interactive query system that runs under IBM’s 
IMs DB/Dc (data base/data communications). It 
employs an easy to use language, has rapid access 
to on-line ms data bases, and provides both man- 
ual and automatic searches on an interactive. 
basis. 

For more information on AsI-st, see Refer- 
ences 3 and 11. Details on Conversational Asi-stT 
can be obtained from ASI, Reference 11. 


Supplemental languages 


Another way of providing computer services to 
a broader range of “programmers” is to supple- 
ment a conventional language (such as CoBoL) 
with one or more higher level languages. The goal 
in such a procedure would be to provide end users 
with an easier way to retrieve and process data— 
for answering inquiries, for preparing ad hoc re- 
ports, and for performing special analyses. 

Conversational Asi-st falls into this category, 


as do the commercial query and reporting pack- 


ages. As mentioned earlier, we are not discussing 
the query and reporting packages in this report 
becasue of their inability to handle validation 
functions and updating functions. 

We have singled out two languages to illustrate 
this category of supplemental languages. These — 
are Ramis and APL. Some people might object to 
this classification on the grounds that either might 
be considered a “complete” language, capable of 
replacing conventional high level languages. But 
for business data processing, we believe that lan- 
guages such as Ramis and APL will be used in addi- 
tion to the conventional languages, as we hope 
the following discussion will explain. 


10 


RAMIS 

Esmark, Inc., with headquarters in Chicago, II- 
linois, is a holding company formed in April 1973 
which has major interests in food, chemicals, in- 
dustrial products, energy, insurance, and business 
and financial services. It has four sub-holding 
companies, one of which is Swift & Company, a 
diversified food complex; each sub-holding com- 
pany owns several subsidiary companies. Esmark’s 
annual sales are in the order of $4.6 billion and it 
employs some 33,500 people. 

In 1971, the people at Swift & Co. saw a need 
for a financial planning model. After considering 
a number of alternative ways to obtain the model, 
they awarded a consulting contract to MATHE- 
MATICA, Inc., of Princeton, New Jersey. In addition 
to bringing model-building talent to the job, 
Mathematica also made available its Ramis sys- 
tem for both programming and running the 
model. Ramis is a data management, information 
retrieval, and reporting system that can be run in 
either a batch or an on-line mode. Ramis can be 
licensed or leased from Mathematica or Ramis 
service can be obtained from National css Inc. 
timesharing. The availability of Ramis was one of 
the factors in Esmark’s selection of Mathematica. 
They purchased Ramis so that it could be run on 
the computers of their data processing subsidiary, 
Cogna Systems Corporation. 

The characteristics of the financial planning 
model give some idea of how Esmark has used 
Ramis. The Esmark planning cycle occurs twice a 
year. In the spring of each year, the strate- 
gic, 5-year plans are developed. Lots of “what 
if’ questions are analyzed—“what would be the 
effect on our financial statement if project X 
was started two years later?” and so on. Alterna- 
tive courses of action are developed. During the 
summer months, these alternatives are studied, 
revised, sharpened. Then in the fall, the 
management plan is developed. This is the 5-year 
plan for the overall corporation, with greatest 
emphasis placed on the first year. After it has been 
developed, the management plan is presented to 
the Esmark Board of Directors. After the Board 
has approved (and perhaps revised) the plan, it is 
used by the various components of Esmark for de- 
veloping their monthly operating budgets. 

The model was developed by Esmark (Swift & 
Co.) staff members working with the Mathema- 
tica consultant. The.consultant then programmed 
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the model on Ramis. That first year, we were told, 
was a real challenge. The development and pro- 
gramming of the model was a problem, of 
course—but the real challenge came in getting the 
financial data in shape in a one-week period. 
Validating the data requires that the data be ana- 
lyzed in several different but related ways, to 
make sure that it is accurate and consistent. The 
data, which had been supplied by the sub-holding 
companies, was put into a Ramis file and all vali- 
dation tests were performed on it in that file. 

Validating the financial planning data contin- 
ues to be a challenge, so Esmark has adopted a 
change in procedure. A terminal has been in- 
stalled at each of the sub-holding companies, for 
input to the Cogna computer, on a remote batch 
basis. Each sub-holding company develops its 
own planning data file and validates it, using 
Ramis. When the validations have been com- 
pleted, Cogna consolidates the files of the four 
sub-holding companies and transfers the resultant 
file to National css. The people at Esmark head- 
quarters use National css for developing the plan- 
ning reports because of the excellent turnaround 
that National css provides. 

In addition, a number of other uses of Ramis 
have developed within Esmark headquarters and 
within the several sub-holding companies. 

We asked about the training required in order 
to use Ramis. There are really two types of users 
within Esmark, we were told. A number of them 
simply retrieve data from Ramis files. Training for 
this function is relatively simple, they say—per- 
haps one hour of training in order to get useful 
output, plus more training and experience to 
learn various ways to format reports. The other 
type of user must validate input data and write 
programs for updating Ramis files. While the 
people who perform these functions are not class- 
ified as programmers at Esmark, they have many 
characteristics of trained programmers. But a 
good Ramis programmer is different from a good 
conventional programmer, we were told; Ramis 
has high level languages and the programmer 
must learn to program within the constraints of 
these high level languages. It takes at least two 
months of training and job experience before use- 
ful applications system output is obtained for this 
type of Ramis use, say the people at Esmark. 
~ In the main, Ramis is a user-oriented informa- 
tion and data retrieveal system. Actually, it is 


1] 


more than that, as its main components will in- 
dicate. Languages: Ramis has an English-like 
report request language plus a high level 
programming language for file maintenance, up- 
dating, and simple input validation functions. 
Ramis also interfaces other languages such as 
Coso., ForTRAN, and pL/1. Generally, complex 
input validation and mathematical routines are 
programmed in these other languages. Data files: 
Ramis provides hierarchical and network struc- 
tures for data. System software: the Ramis system 
software catalogs requests, retrieves requests from 
the catalog, and supervised the sequence of activi- 
ties in the running of Ramis jobs. Equipment: 
Ramis is designed to operate on IBM 360/370 
computers under all versions of os. It is also avail- 
able via National css Inc. 

For more information on Ramis, see References 
3 and 12. 


APL 


Some readers may wonder why we are in- 
cluding a mathematically-oriented language such 
as APL in a discussion of business languages. The 
reason is that we have found apt being used as a 
supplemental language in a growing number of 
business environments. It is becoming sufficiently 
important in this respect, as a matter of fact, that 
we hope to devote a complete report to it in the 
not-distant future. The following discussion will 
only treat some of the high points of its use. 

The British Steel Corporation, with headquar- 
ters in London, England, is the nationalized con- 
solidation of the major U.K. steel companies. 
British Steel produces about 25 million metric 
tons of steel per year, and employs some 230,000 
people. The corporation does not have a com- 
puter installed at its headquarters but uses 
installations at its plants, at its research centers, 
or uses outside services, depending upon the 
application. 

The Planning Department of British Steel, 
among its other responsibilities, produces an eco- 
nomic plan on a year-by-year basis, for ten years 
in the future. This economic plan includes a fore- 
cast of sales, prices, the need for additional fa- 
cilities, and so on. An economic planning model 
has been created for this function, written in 
FORTRAN. 

In addition, the department performs specific 
planning studies that go into more detail than the 
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10-year economic plan. One such study, begun in 
1973, was concerend with selecting the most 
profitable strategy for the production of billets. A 
billet is a piece of partially completed steel, about 
four inches square and from 20 to 60 feet long. 
The study involved forecasting the sales of billets 
over a ten year period. A number of alternate 
strategies were defined which allocated produc- 
tion to the plants over a multiple year time pe- 
riod. The goal was to insure efficient overall 
production as well as to provide a basis for costing 
and evaluating the profitability of the strategies. 
The problem was reasonably complex, with some 
60 different types of billet, 15 plants with differ- 
ing production characteristics, and 12 different 
strategies. In adddition, each plant was poten- 
tially capable of being expanded or closed. The 
approach which was selected made use of two 
models, one to perform the allocation and the 
other to evaluate the strategies. 

One member of the Planning Department had 
seen a demonstration of the apt service offered in 
London by I. P. Sharp Associates Limited, of To- 
ronto, Canada. He was impressed with how well 
APL handled arrays, and felt that British Steel 
should give it a try. So the strategy evaluation 
sub-model was selected as the pilot test of APL 
within British Steel. The model would not use 
linear programming, but instead would use a 
straight-forward logic, easily understandable by 
the people in the plants. If the model were pro- 
grammed in ForTRAN, they already knew the dif- 
ficulties they would face when they wanted to get 
at the data or change the model. With apt, it 
looked as though the economists themselves, 
working at a terminal, could easily retrieve de- 
sired data, perform analyses, and make changes in 
the model. 

British Steel gave a contract to I. P. Sharp Asso- 
ciates to write the model in apL. The work was 
done during a two month period in early 1974 by 
Keith Iverson (the son of Dr. Kenneth Iverson, the 
creator of APL) who works for Sharp. British Steel 
was delighted with the results. Apt in fact did 
give the Planning Department a much easier in- 
terface with the computer. 

Based on the results of this pilot test, the Plan- 
ning Department asked British Steel’s Operations 
Research Department to write the allocation sub- 
model in APL. The or people had no difficulty in 
learning to use APL, and in fact, found it a very 
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logical language as compared to ForTRAN. So 
British Steel expects to expand their use of APL 
in the future. 

A discussion of the history and characteristics 
of APL can be found in References 1 and 4. The 
language was created by Dr. Kenneth Iverson in 
the early 1960s, while working at Harvard Uni- 
versity and later at an IBM Research Center. It 
was described in an early book, A Programming 
Language, by Iverson (Wiley, New York, 1962). 
But apx did not catch on as a programming lan- 
guage in a batch environment. It was not until the 
late 1960s, when it was implemented as an inter- 
active language, that it began to become popular. 

APL uses a very concise, symbolic notation. The 
notation tends to scare off some programmers 
from the use of apL. The notation is so powerful 
that programmers can write meaningful one-line 
programs. The intent of such “one liners”’ is often 
not clear to another programmer—or to the pro- 
grammer who created it at a later point in time. 
(In fact, we understand that a game has been 
made of this, where one programmer shows a one- 
liner to another programmer and says, “Bet you 
can't tell me what this does.”) However, the in- 
tent of the language is to provide powerful oper- 
ators, not to write one-liner programs whose 
function is unclear. In fact, in Reference 4, it is 
reported that apx has been successfully taught at 
the seconday school level. 

Becasue of the power of the APL operators and 
the conciseness of the language, it is reported that 
coding time can be reduced up to 90%. 

As mentioned earlier, we plan to return to the 
subject of APL in a not-distant report. For more in- 
formation on APL, see References 13a and 13b. 


The future—non-procedural languages? 


Philippakis, in Reference 5, reports the results 
of a survey he conducted on the use of various 
programming languages in business environ- 
ments. He sent out 390 questionnaires and re- 
ceived 164 responses, from a variety of types and 
sizes of companies. While he cautions against at- 
taching too much precision to the results, the fig- 
ures give a general impression of language usage. 


He computed a “usage index” as the product of | 


the percent of users using a language and the 
average percentage of the time they used it. The 
results were: CoBoL, 59; assembler, 20; report 
generator type language, 6; ForTRAN, 5; PL/I, 4; 
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other, 3; Basic, 1; APL, 0. 

His results are not surprising. Cosot clearly 
shows up as the leader in business data processing, 
with some form of assembly language second. Ap- 
parently the structured generator languages are 
used more than either ForTRAN or PL/I, and that 
is a point of interest (certainly considering IBM’s 
efforts to push pL/1 for much of the past decade). 
While two companies reported using api, the 
usage was so small that his usage index was zero 
for this language. 

One point should be emphasized. The amount 
of use was measured as the approximate man- 
hours of programming in each language per one 
hundred man-hours of programming. Higher 
level languages, such as we have discussed in this 
issue, would therefore be penalized in multi- 
language shops. Conventional languages, such as 
CoBoL, ForTRAN, and assemblers, would get 
higher usage indexes because they require more 
man-hours of use to accomplish a job, as com- 
pared with the higher level languages. 

A follow-on study in another two years or so 
would be interesting, to see what the shifts in 
usage might be. We would expect to see a meas- 
urable shift toward higher level languages. But 
again, the figures might be misleading if amount 
of usage is measured in man-hours. 

It is clear, of course, that the bulk of the pro- 
gramming being done today uses procedural lan- 
guages. Non-procedural functions—such as open 
and close files, record reading and writing, file 
matching, etc.—have appeared in some of the 
higher level languages. Macros are being used to 
eliminate the need of rewriting detailed proce- 
dures for frequently performed actions. Ap has 
introduced powerful operators, perhaps not un- 
like macros for the handling of arrays, to elimi- 
nate the need for some detailed procedures. So 
progress is being made in the direction of non- 
procedural programming. But the fact remains 
that all of the languages discussed in this report 
still require procedural programming. 

What will happen in the next few years? Our 
guess is that users will attempt to reduce devel- 
opment and maintenance costs by moving toward 
the higher level languages, such as the ones we 
have discussed. These languages may well be en- 


hanced over what is available today, by the addi- 


tion of more non-procedural functions. But in 
general, the languages will look very much as 


13 


they do today. Custom-programmed detailed 
procedures will still be needed by users for those 
activities that are not covered, or not covered ad- 
equately, in the non-procedural portions of the 
languages. 

When will the “true” non-procedural lan- 
guages appear, where one need only specify what 
is desired rather than how to achieve it? Based on 
the progress of the past ten years or so, we can- 
not yet foresee the arrival of the “true” non- 
procedural language. 

But maybe the “true” non-procedural language 
is an ideal that will never be reached. Maybe it is 
important only as a goal to strive for, not as some- 
thing that the field should be eagerly awaiting. In 
that case, we would expect to see significant prog- 
ress in the next five years. The languages that we 
have discussed in this report have, in general, 
been well enough received in the marketplace 
that their suppliers will continue to improve 
them. We have discussed how several of them 
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have been enhanced over the past several years, 
and there is every reason to expect that the im- 
provements will continue. 

What does all of this mean to you? As we see it, 
the picture of higher level languages for the next 
five years or so is reasonably clear. They will look 
very much like today’s higher level languages. If 
you are interested in gaining the advantages of 
such higher level languages, there seems to be no 
good reason for waiting. Select which basic 
course of action you prefer—CosBo.-based HLL, 
structured generator language, or supplemental 
language—and start using it. During the next five 
years, you will be able to obtain a series of im- 
provements to the language of your choice, in all 
likelihood. | 

And by the end of this decade, you might be 
quite surprised how “non-procedural” your pro- 
gramming has become, as compared with today’s 
conventional languages. | 


8. For more information on CL*1v, write Informatics MARK 
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Park, Calif 91304. 

9. For more information on GENAsys, write to Inter- 
national Computer Trading Corporation, 465 California 
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10. For more information on Adpac, write to Adpac Com- 
puting Languages Corp., 101 Howard Street, San Fran- 
cisco, Calif 94105. 

11. For more information on Conversational Ast1-st, write to 
Applications Software Inc., 21515 Hawthorne Blvd., 
Torrance, Calif. 90503. 

12. For more inforamtion on Ramis, write MATHEMATICA, 
Inc., P.O. Box 2392, Princeton, New Jersey 08540. 

13. For more information on APL: 

a) Write I. P. Sharp Associates Ltd., Suite 1400, 145 
King Street West, Toronto, Ontario, Canada. 

b) Datapro Feature Report, “All about remote com- 
puting services,” (address above), February 1975, 
price $10; lists a number of services that offer APL. 
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